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Beschreibung 

Verfahren zum Ubermitteln von geschiitzten Inf ormationen an 
mehrere Empfanger 

5 

Fachgebiet der Erf indung 

Die Erf indung betrifft ein Verfahren gemaJJ der unabhangigen 
Anspriiche 1 und 2 . 

10 

In den vergangenen Jahren ist es immer popularer geworden, 
iiber die verschiedenen Kommunikationsnetze Dienste in An- 
spruch zu nehmen oder Waren zu erwerben. Ein Hinderungsgrund 
war fur den Benutzer bisher immer, dass auch sensible Daten, 
15 wie Kontoinformationen, uber das Netz ubertragen werden mus- 
sen . 

In der Figur la ist ein Kaufvorgang vorgestellt, wie er der- 
zeit beispielsweise im Internet durchgefiihrt wird. Auf der 
einen Seite steht der Kunde (Consumer) , der bei einem Verkau- 

20 fer (Merchant) Waren erwirbt. Die Bezahlung dieser Waren soli 
iiber sein Bankkonto erfolgen. Der Kunde iibermittelt nun seine 
Warenanf orderung an den Verkaufer, hier sind verschiedene In- 
formationen denkbar, wie Zusatzinf ormationen uber den Kunden 
(Zusatzinfo) , eine Angabe uber die gewlinschten Waren (Goods), 

25 sowie Information iiber die gewunschte Zahlunsweise, bei- 
spielsweise eine Kreditkartennummer . 

Diese Inf ormationen werden dem Verkaufer iibermittelt, etwa 
uber eine gesicherte Leitung (SSL, Secure Socket Layer, und 
TLS, Transport Layer Security, eine gesicherte Verbindung) . 

30 Diese Verbindung kann zwar von Fremden nicht abgehort werden, 
jedoch erhalt so auch der Verkaufer Inf ormationen, die nicht 
unbedingt fur ihn bestimmt oder zum AbschluB des Kaufvertra- 
ges notwendig sind, wie eben die Kreditkartennummer. Der Ver- 
kaufer leitet diese Inf ormationen vollstandig an die Bank 

35 weiter, insbesondere auch die Information iiber die gekauften 
Waren, die nicht fur die Bank bestimmt sind. 
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Gewiinscht ware jedoch ein Verhalten, wie es in der Figur lb 
dargestellt ist, so dass der Verkaufer nur die fur ihn wich- 
tigen In format ionen iiber die bestellten Waren erhalt und die 
Bank nur die fur sie wichtigen Inf ormationen iiber das Konto 
5 des Kunden. 

Stand der Technik 

10 Verschiedene Losungen sind bereits bekannt . Ein bekanntes 
Produkt auf dera Gebiet der elektronischen Bezahlverf ahren 
wird von der Firma SET Secure Electronic Transactions Lie. 
angeboten . Eine Beschreibung des bekannten Verfahrens findet 
man in der Spezif ikation der Software, die auf ihrer Webseite 

15 http : / /www . setco , org/extensions . html abgelegt sind. Hier fin- 
det sich eine Datenstruktur , die durch zusatzliche Erweite- 
rungen, sogenannte "extensions", anwendergerecht erganzt wer- 
den kann . 

20 Auch in dieser Losung von SET wird jedoch keine Moglichkeit 
angegeben, verschiedene inhaltlich zusammengehorende Informa- 
tionen, beispielsweise Kreditkartennummern mehrerer Anbieter 
oder Kontoangaben verschiedener Banken, zusammen in einer Da- 
tenstruktur abzulegen. 

25 

Aufgabe der Erfindung ist es also, ein Verfahren zum Ubermit- 
teln von Inf ormationen anzugeben, welches es den Empfangern 
ermoglicht, die fur sie bestimmten Teile der Informationen zu 
lesen. Aufgabe ist es weiterhin, mehrere inhaltlich zusammen- 
30 gehorige Daten in einer einzigen Datenstruktur geschiitzt zu 
ubermitteln. 

Diese Aufgabe wird gelost durch ein Verfahren gemaft des Pa- 
tentanspruchs 1 und durch ein Verfahren gemaJi des Patentan- 
35 spruchs 2 . 

Gemaft dem Patentanspruch 1 werden erste Informationen, die 
fur einen ersten Empfanger, im weiteren auch Anbieter ge- 
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3 

nannt, bestimmt sind, zusammen mit zweiten Informationen, 
welche fur einen zweiten Anbieter bestimmt sind, in einer ge- 
meinsamen Inf ormationseinheit versendet. Die ersten Informa- 
tionen konnen dabei gemafl den Vorgaben des ersten Anbieters 
verschlusselt sein. Die zweiten Informationen, welche aus 
mehreren Bestandteilen bestehen konnen, werden gemaft den Vor- 
gaben des zweiten Anbieters verschlusselt, beispielsweise mit 
einem offentlichen Schlussel, einems sogenannten "public 
key". Diese "public key" Verschlusselungsverf ahren sind be- 
reits in verschiedenen Ausfuhrungen und Sicherheitsstuf en be- 
kannt. Durch dieses Vorgehen wird gewahrleistet, dass der 
erste Anbieter bei Erhalt der kompletten Information die fur 
ihn nicht bestimmten Inf ormationsanteile nicht entschliisseln 
kann. 



Der Empfanger der Nachricht wird im weiteren auch Anbieter 
genannt, da in den beschriebenen Beispielen im wesentlichen 
auf einen Kaufvorgang im Netz eingegangen wird. Hier ist der 
erste Empfanger der Nachricht ublicherweise ein Verkaufer, 
20 also ein Anbieter von Waren und Dienstleistungen, der zweite 
Empfanger der Nachricht eine Bank oder Geldinstitut , also ein 
Anbieter von Finanzdienstleistungen . Diese Beschreibungen 
sind jedoch nicht einschrankend gemeint. 

Andere Konstellationen sind vorstellbar, beispielsweise ein 
25 Anbieter von Inf ormationen, der auf weitere Datenbanken zu- 
greift, ein erster Netzbetreiber, der auf ein Netz in einem 
fremden Land zugreift, ein Automobilhersteller oder Polizei, 
die auf die Datenbank der Kf z-Anmeldestelle zugreifen. 

30 Patentanspruch 2 gibt eine alternative Losungsmoglichkeit an, 
bei der die Inf ormationen, welche fur den zweiten Anbieter 
gedacht sind, nicht mit den ersten Inf ormationen zusammen in 
das Netz geschickt werden, sondern bei Bedarf von dem Inf or- 
mationsempf anger aus einem zentralen Speicherbereich im Netz 

35 abgeholt werden konnen. 
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Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den 
Unteranspruchen angegeben. 

Als besonders vorteilhaft hat sich eine Realisierung der er- 
findungsgemafien Losung gemafi dem bereits bekannten Standard 
5 X.509 erwiesen (Series X: Data Networks and Open Systems Com- 
munication - Directory: Public Key an Attribute that Certifi- 
cate Frame Works f ITU-T Recommendation X.509) . Eine Realisie- 
rung mit dem X.509-Standard birgt mehrere Vorteile in sich, 
denn dieses Vorgehen ist bereits standardisiert, und kann un- 
10 abhangig von bereits vorhandenen Implementierungen verwendet 
werden. Eine Definition der Datenstrukturen erfolgt in ASN.l 
Notation, welche ebenfalls seit Langem standardisiert ist und 
implementierungsunabhangig angewendet wird . 

15 Besonders vorteilhaft erweist sich das erf indungsgemafie Ver- 
fahren bei den bereits angesprochenen Zahlungstransaktionen, 
die notwendig werden, wenn man Daten, Inf ormationen und Waren 
liber das Internet oder ein sonstiges Kommunikationsnetz be- 
stellt oder bezieht und auch die Bezahlung uber das Netz ab- 

20 wickeln mochte . 

Im Rahmen der bereits bekannten Transaktionen uber Netze hat 
es sich bewahrt, einem Vorgang eine sogenannte Transaktions- 
nummer (TAN) zuzuweisen, welche einen Kaufvorgang im Netz 
25 eindeutig beziffern und auch nachtraglich zuruckverf olgen 
lassen. 

Die Realisierung der Information durch Ablage in einer Erwei- 
terung eines Zertifikats gemali dem Standard X.509 kann in 
30 zwei verschiedenen Variationen erf olgen. 

Man kann dieses Zertifikat als sogenanntes Identity Certifi- 
cate realisieren, dieses ist beschrieben im ITU Standard 
X.509/ Section 2. Vorteilhaft ist bei dieser Ausfuhrung, dass 
35 das Zertifikat sehr kompakt wird, man hat eine "all in one"- 
Ldsung . 
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Ein Zertifikat in dieser Form ist allerdings im Nachhinein 
nicht mehr anderbar. Daher gibt es als Alternative die Reali 
sierung in einem sogennannte "Attribute Certificate". Die Be 
schreibung hierzu findet sich in der Section 3 des bereits 
5 genannten Standards. Das hat den Vorteil, dass die einzelnen 
Erweiterungen (Extensions) dieses Zertifikats unabhangig von 
einander sind, deshalb kann man sie jederzeit andern. Ein 
Zertifikat muss auch nicht widerrufen werden, man muss nur 
abwarten, bis seine Lebensdauer abgelaufen ist. In diesem 
10 Fall wird das System allerdings komplexer. Der Benutzer muss 
verschiedene Zertifikate behandeln und der Ausgebende der 
Zertifikate muss mehr Certificate Revocation Lists (CRL) ver 
walten . 

Wahlt man zur Realisierung die zweite Losung, die Attribute 
15 Certificate Extension, so hat man hier noch die Auswahl, ob 
dieses Zertifikat genau einmal verwendet werden kann, eine 
sogenannte "One Time Use" oder als sogenannte "Long Life Use 
einen bestimmten Zeitraum vorgibt, in dem das Zertifikat gul 
tig ist. 

20 

Zur Ablage des Zertifikats und dazugehorige privaten Schlus- 
sel ist ein geeignetes Speichermedium denkbar, auch wenn das 
Zertifikat zentral im Netz abgelegt wird. Der Eigentumer des 
Zertifikats kann dieses auch auf eine Smart Card oder einen 
25 Smart Dongle, auf einem kontaktlos abzulesendem Speichermedi 
urn oder ahnlichem speichern. Hierbei ist es besonders vor- 
teilhaft, wenn das abgelegte Zertifikat zusatzlich durch ein 
Passwort, eine PIN usw. vor unberechtigtem Zugriff geschiitzt 
wird. 

30 

Das beschriebene Verfahren kann selbstverstandlich fur alle 
Nutzerinformationen verwendet werden, neben der Kreditkarten 
nummer, wie Adresse, Blutgruppe, Versicherungsnummern etc.. 

35 Das vorgeschlagene Vorgehen hat gegenuber dem bereits bekann 
ten Verfahren verschiedene Vorteile. 
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Eine Verschliisselung und Signierung der Inf ormationen mit be- 
reits bekannten Verfahren ist jederzeit moglich. Dadurch wird 
der Schutz vor unberechtigtem Zugriff (die Privacy) der In- 
f ormationen gesichert. 
5 Der Diebstahl von Kreditkartennummern f wie es bisher bei- 
spielsweise durch Abhoren der Kauf transaktion geschah, wird 
weiter erschwert . Durch eine zusatzliche Sperre des Zugriff s 
auf gespeicherte Inf ormationen auf dem Speichermedium durch 
Einfuhrung einer PIN wird der Schutz weiter erhdht- 

10 

Kurzbeschreibung der Z e i chxxunge n 

Im Folgenden wird die Erfindung anhand von Ausf uhrungsbei- 
15 spielen erlautert. Dabei zeigen 

Figur la eine Ubersicht uber die Verbindungen, die derzeit 
bei einem Kaufvorgang aufgebaut werden, wenn der Kaufer die 
Bezahlung uber einen Zahlungsdienstanbieter im Netz vornimmt, 

20 

Figur lb zeigt denselben Vorgang, wenn das erf indungsgemafie 
Verfahren auf den Zahlungsvorgang verwendet wird, 

Figur 2a zeigt die Zertif ikatserweiterungen fur mehrere Kre- 
25 ditkarten oder ahnliche Inf ormationen, 

Figur 2b zeigt die neuen Primaten OID gemafi X.660 

Figur 3a zeigt das beispielhaf te Format ftir eine Kundenanfor- 
30 derung bei einem Kaufvorgang, 

Figur 3b zeigt das Format fur die Antwort des ersten Anbie- 
ters, 

35 Figur 3c zeigt das Format fur die signierte Erwiderung des 
Kunden, 
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Figur 3d zeigt das Format fur die Authentisierungsdaten vom 
zweiten Anbieter, ebenfalls signiert, 

Figur 3e zeigt das Format fur eine zweite Kundenanf orderung, 

Figur 3f zeigt das Format fur eine dritte Kundenanf orderung, 

Figur 3g zeigt das Format fur eine vierte Kundenanforderung, 

10 Figur 3h zeigt ein weiteres beispielhaf tes Format fur die Au- 
torisierungsdaten vom zweiten Anbieter, ebenfalls signiert, 

Figur 4 zeigt einen Kaufvorgang in vier Schritten, 

15 Figur 5 zeigt einen Kaufvorgang in acht Schritten, 

Figur 6 zeigt einen Kaufvorgang in zehn Schritten, 

Figur 7 zeigt einen Kaufvorgang mit auftretenden Fehlern, 

20 

Figur 8 zeigt die Struktur des SICRYTT Secure Token, 

Figur 9 zeigt die X.509 Zertifikat Extension Struktur. 

25 Die Figuren la und lb zeigen, wie in der Einleitung bereits 
beschrieben, den beispielhaf ten Ablauf eines Kaufvorganges . 
In den Kasten uber den Pfeilen dargestellt, sind die jeweili- 
gen Inf ormationen, die zwischen den einzelnen Verfahrensteil- 
nehmern flieften. Der Kontakt des Kaufers (Consumer) geschieht 

30 immer uber den Verkaufer (Merchant) . Eine direkte Kommunika- 
tion des Kaufers zur Bank findet nicht statt. Alle Inf ormati- 
onen flieflen uber den Verkaufer. Dies hat zur Folge, dass der 
Verkaufer auch Inf ormationen erhalt, die fur seinen Verkaufs- 
vorgang unerheblich sind. Durch das erf indungsgemafie Verfah- 

35 ren, wie in Figur lb dargestellt, werden dem Verkaufer zwar 
samtliche Inf ormationen ubersendet, er kann diese jedoch 
nicht uneingeschrankt lesen. Beispielsweise die Zahlungsin- 
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formation (z.B. Kreditkarten-Nummer, Credit Card Info) , wie 
hier durchgestrichen dargestellt, ist dem Verkaufer nicht an- 
gezeigt. Andere Inforcnationen, etwa wer der Kunde ist (Zu- 
satz-Info, User Info) und was dieser Kunde bestellen mochte 
5 (Waren, Goods) sind ihm frei zuganglich. 

Heutige Public Key Zertifikate versuchen, ein Zertifikat 
(Public und Private Key) auf ein vollstandiges Userprofil ab- 
zubilden. Allerdings hat sich die Anzahl der Anwendungen er- 
10 weitert, so dass mehr als eine Anwendung (in Zusammenhang mit 
beispielsweise Webdiensten) benotigt werden. 

Die erf indungsgemafle Idee verwendet hierfiir ein bereits be- 
kanntes X.509 Zertifikat und erweitert dieses durch zusatzli- 
che Inf ormationen . Diese Inf ormationen werden verschltisselt 
15 und in dieser Form im Zertifikat abgespeichert . Eine Darstel- 
lung hierfiir findet sich in Figur 2a. 

Der ursprungliche X.509 Standard wurde entworfen, urn einen 
weltweit einheitliche Namen zu entwickeln fur Benutzer in ei- 
nem Netz, ohne doppeltes Vorkommen, in einem sogenannten 

20 X.500 Directory. Das X.500 Directory ist eine Datenbank, die 
fur weltweiten Gebrauch bestimmt ist, wie ein weltweites Te- 
lefonbuch. Das X.509 Zertifikat wird digital signiert und 
durch eine Zertif izierungsautoritat ausgegeben, urn die Iden- 
titat des Inhabers und zusatzliche Inf ormationen zu bestati- 

25 gen. Public key Verfahren sehen vor, urn sicher mit anderen 

Telnehmer zu kommunizieren, zwei Schlussel zu generieren: ein 
privaten Schlussel (der geheim bleibt) und einen offentlichen 
Schlussel, der an jeden weiter geben werden kann. Das X.509 
Zertifikat verbindet den offentlichen Schlussel und den Namen 

30 des Inhabers des privaten Schliissels. 

Vorteil des X.509 Standards ist es, dass er fur eine allge- 
meine Verwendung entwickelt wurde. Hier wird das ganz allge- 
meine Problem der Authentisierung in verteilten Systemen ge- 
lost und sein Losungsentwurf ist implementierungsunabhangig. 

35 

In der Version 3 des X.509 Standards, der 1996 verof f entlich 
wurde, wurden sogenannte Extensions eingefuhrt, bei denen je- 
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derraann zusatzliche Datenfelder implementieren und diese in 
seine Datenstruktur einfuhren kann . Diese Erweiterungen wer- 
den auch Private, Proprietary, oder Custom Extensions ge- 
nannt . Sie tragen eindeutige Informationen, die fur den Zer- 
5 tifikatinhaber oder Zertif ikataussteller wichtig sind. 

Bislang bekannte Erweiterungen sind heute sogenannte "Key U- 
sage Limits", die die Verwendung eines Schliissels auf einen 
speziellen Verwendungszweck beschranken, oder "Alternative 
Names", die der Verknupfung des Offentlichen Schliissels (Pub- 
10 lie Keys) mit anderen Namen wie: Domain Namen, E-Mailadressen 
etc. ermoglicht. Diese Zertif ikaterganzungen konnen auch als 
kritisch markiert werden urn anzuzeigen, dass die Erganzung 
uberpruft werden muss. 

15 Im beispielhaften Fall eines Zahlungsverkehrs teilt der Be- 

nutzer mit verschiedenen Teilnehmern verschiedene "Geheimnis- 
se", also Daten, die nur dem direkten Kommunikationspartner 
bekannt gegeben werden sollen, beispielsweise bei einem Kre- 
ditkartenausgebenden, wie American Express, Visa, Master Card 

20 etc., eine Kreditkartennummer oder mit einer Bank die Konto- 
nummer oder mit einer Versicherungsanstalt die Versicherungs- 
nummer. Weitere personliche Informationen, wie beispielsweise 
die Adresse, sind vorstellbar. 

Nur der Besitzer des Zertifikats kennt alle diese Erweiterun- 
25 gen. Jede einzelne Erweiterung wird dann so verschlusselt, 
dass nur die jeweilige Partner mit der richtigen Identitat 
die entsprechenden Daten wieder entschlusseln kann. 

Hierfur kann beispielsweise das bekannte Public Key Krypto- 
30 graphie-Verfahren verwendet werden. Zur Verschliisselung wird 
dann der jeweilige offentliche Schliissel der Versicherung, 
der Bank oder des Kreditkartenausgebenden verwendet. Dieses 
wird bei der Ausgabe des Zertifikats verwendet. Danach wird 
das Zertifikat in einem Public Directory abgelegt werden, 
35 weil nur der jeweilige Ausgebende der Information diese mit 
seinem privaten Schlussel entschlusseln (verstehen) kann. 
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Die Erweiterungen sind in dem X . 509-Standard in der ASN.l No- 
tation definiert. Die Figur 2a zeigt eine beispielhaf te Aus- 
gestaltung einer moglichen ausgegebenen Zertif ikaterganzung 
fur einen Benutzer. Dieser Benutzer besitzt drei verschiedene 
5 Kreditkarten (Visa, AnieX, Mastercard) , ein Bankkonto (Bankac- 
count), weiterhin ist seine Adresse kodiert (Address) und ei- 
ne Versicherungsnummer (Social Insurance Number) . 

Die einzelnen Erweiterung werden durch sogenannte "Object I- 
10 dentifier" (OID) identif iziert . Diese ist eindeutig f was be- 
deutet, dass beispielsweise alle Felder, in denen eine Kre- 
ditkarten nummer von einem speziellen Kreditkarteninstitut 
(beispielsweise Visa) immer dieselbe Object ID hat- Im ge- 
zeigten Beispiel der Figur 2b ist diese OID, diese sogenannte 
15 Nummer 1.3.6.1.4.15601.1. Die Definition dieser Object Iden- 
tifier OID befindet sich in der ITU-T Recommendation X.660. 
Die OID kann entweder in einer Baumstruktur abgelegt sein, 
das bedeutet, alle Extensions haben denselben Elternknoten . 
Dieser Fall ist in der Figur 2b dargestellt. Es ist aber auch 
20 moglich, dass die Erweiterungen f irmenabhangig sind. Das be- 
deutet, dass die Erweiterungen an verschiedenen Punktes des 
Baumes eingehangt werden. 

Auch in der Figur 9 findet sich eine Reprasentierung des 
25 X.509 Zertif ikats in Baumstruktur. Weiterhin ist in der Figur 
9 zu entnehraen, dass diese Erweiterung nicht blofi als eine 
Bezeichnung und einem Wert bestehen kann, sondern durch wei- 
tere Informationen erganzt werden kann. Im beschriebenen Fall 
der Figur 9 existiert ein weiteres Feld (Crit.), was symbo- 
30 lisch den Wert "true" oder "false" einnehmen kann. Wird der 
Wert auf true (wahr) gesetzt, so bedeutet dies, dass die Er- 
weiterung als kritisch zu interpretieren ist. Eine mogliche 
Reaktion auf diesen Kritischwert kann sein, dass die Anwen- 
dung, die das Zertifikat erhalt und diese Erweiterung nicht 
35 versteht, das Zertifikat als ungultig zuruckweisen muss. In 
dem Fall, dass das Flag von kritisch auf false gesetzt ist, 
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kann die Anwendung das Zertifikat trotzdern verwenden, auch 
wenn es diese Extension nicht versteht. 

Die Zertifikate konnen auf verschiedene Weise gespeichert 
5 werden . Standard Verfahren ist f diese zentral im Netz in ei- 
nem Directory abzulegen. 

Vorteilhaf terweise kann der Eigentumer des Zertifikats dieses 
aber auch auf einera geeigneten Speichermedium mit sich tra- 
gen. Eine bekannte Methode zur Speicherung von solchen Infor- 

10 mationen sind sogenannte "Smart Cards". Diese Smart Cards 

sind dem Fachmann bereits bekannt. Vorteil bei der Verwendung 
einer Smart Card ist, dass der Zugriff auf den Speicher, in 
dem das Zertifikat (eigentlich der private Schlussel) abgelegt 
ist, zusatzlich durch eine PIN oder entsprechendem PaBwort 

15 geschiitzt werden kann. Im Falle rnehrfacher falscher PIN- 
Eingabe wird dann der Zugang zum Speicher der Karte bio- 
ckiert . 

Andere Speichermedien sind jedoch vorstellbar. 

In der Figur 8 findet sich eine Darstellung der Infineon Sic- 
20 ript Secure Token Plattform. Diese Plattform bietet zwei Stu- 
fen an Speicher zugang an. Der Userlevel ist mit einer soge- 
nannten "User PIN" geschiitzt und der zweite Level mit einer 
weiteren "Administrator PIN". Diese "Administrator PIN" kann 
verwendet werden, urn nach mehrfachem falschen Eingeben der 
25 "User PIN" die Karte wieder zu entsperren. 

Das. Speichern des Zertifikats auf einer Smart Card hat diese 
Vorteile : 

Sicherheit : 

30 Das X.509 Zertifikat und der zugehorige private Schlussel 

werden in zwei verschiedenen sogenannten "Elementary Fi- 
les" (EF) abgespeichert, siehe Figur 8. Der schreibende 
Zugriff zu der entsprechenden Datei DF c $p ist mit einem Zu- 
gangscode geschiitzt. Das Elementary File EF Key paic ist ge- 

35 nauso geschiitzt. Jede Anwendung oder jeder Dienst, der den 

Zugriff zu dem privaten Schlussel bendtigt, muss genau 
diesen Zugangscode vom Benutzer erhalten. Dahingegen kann 
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die Ablage des EF Ce rtificate immer gelesen werden, ist also 
nicht geschiitzt. Das Zertifikat in das System zu propagie- 
ren bedeutet in diesem Fall also lediglich das Kopieren 
des Zertifikats zu dem System* 

5 

Mobilitat: 

Smart Cards sind tragbare Speichermedien und wegen ihrer 
Groiie kann der Benutzer sie beispielsweise in seiner 
Brief tasche mit sich tragen. Weiterhin kann er sie an sei- 

10 nem PC mit einem entsprechenden Lesergerat verwenden, ge- 

nauso an offentlichen Terminals (beispielsweise in einem 
Internetcafe) . Der Benutzer braucht dabei nicht zu be- 
furchten, dass der private Schlussel kopiert wird oder im 
System verbleibt. Auch wenn der Benutzer seine Smart Card 

15 verliert, kann auf diese ohne den Zugangscode (PIN) nicht 

zugegriffen werden. 

Kompaktheit: 

Durch das erf indungsgemafte Abspeichern der verschiedenen 
20 Zahlungsmoglichkeiten (beispielsweise alle Kreditkarten- 

nummern und alle Kontonummern) auf einer Karte, ist diese 
besonders kompakt . Ein derartiges Abspeichern in einer Da- 
tenstruktur ist dem Fachmann bislang nicht bekannt. Wei- 
terhin konnen weitere Inf ormationen (zum Beispiel die Ad- 
25 resse usw.) integriert werden und machen das Userprofil 

damit noch kompakter. 

Im Folgenden wird nun die Durchfiihrung eines Zahlungsvorgangs 
mit dem X.509 Zertifikat beschrieben. In den Figuren 3a bis 

30 3h sind verschiedene Moglichkeiten der einzelnen Nachrichten 
abgebildet, die vom Nutzer f dem Verkaufer oder der Bank im 
Verlauf des Zahlungsvorgangs benutzt werden konnen. 
Die Ubermittlung dieser Nachrichten erfolgt beispielsweise 
uber das Internet, andere Mobilfunk- oder Festnetze sind vor- 

35 stellbar. 



WO 2005/015514 



PCT/EP2004/051749 



13 

Voraussetzung des Verfahrens ist, dass bereits durch den Nut- 
zer eine Auswahl des Produkts erfolgt ist, sowie der Preis 
fur dieses Produkt verhandelt wurde. Die Nachrichteneinheiten 
werden auf Application Level beschrieben, das bedeutet, es 
5 sind keine Bytestrukturen angegeben. Weiterhin sind die Teil- 
nehmer des Verfahrens'' online", also dauerhaft mit dem Netz 
verbunden . 



In einem beispielhaf ten ersten Ablauf sind der Kunde (Consu- 
10 mer), der Verkaufer (Merchant) und die Bank uber ein Netz, 

beispielsweise das Internet, verbunden. Dies soil aber keine 
Einschrankung fur das Verfahren darstellen, andere Verbin- 
dungsmoglichkeiten sind denkbar. Die Schritte 1 bis 10 der 
Figur 6 werden in sequentieller Folge durchlaufen. Dabei wird 
15 angenommen, dass der Austausch des X.509 Zertifikats zwischen 
dem Verkaufer (Merchant) und der Bank bereits geschehen ist. 



1. Der Kunde fordert vom Merchant (Verkaufer) den offentli- 
chen Schlussel an, sofern er ihn noch nicht hat (Request 
20 Cert. ) . 



2. Der Verkaufer sendete sein Zertifikat (Send. Cert.) an den 
Kunden . 



25 3. Der Kunde validiert das Zertifikat. Dabei uberpriift er 

beispielsweise, ob die Zeitgultigkeit noch nicht abgelau- 
fen ist, und ob das Zertifikat von einer vertrauenswurdi- 
gen Autoritat ausgestellt wurde. Dann sendet der Kunde 
seine Kauf anf orderung an den Verkaufer (Purchase Order) . 

30 Die Kauf anf orderung kann das Format haben, wie es in Figur 

3a dargestellt ist. In diesem Fall sind die Angaben der zu 
kaufenden Waren verschlusselt mit dem offentlichen Schlus- 
sel des Verkaufers (E (Merchant pU biickeyf goods), dagegen ist 
das X.509 Zertifikat nicht verschlusselt. Das Versenden 

35 des X.509 Zertifikats in dieser Nachricht ist optional- Im 

anderen Fall holt sich der Verkaufer dieses Zertifikat aus 
einem offentlichen Verzeichnis. Das Zertifikat ist nur in 
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dem Teil verschlusselt , der die Kreditkarteninf ormation, 
wie vorher beschrieben, enthalt. 

4. Der Verkaufer entschltisselt diese Nachricht mit seinem 

5 privaten Schlussel. Er priift auch hier die Gultigkeit des 

Zertifikats auf folgende Bedingungen: 

1st das Zertifikat von einer vertrauenswiirdigen Autori- 
tat ausgestellt, 

1st die Lebensdauer des Zertifikats uberschritten, und 
10 - 1st das Zertifikat nicht in der CRL (Certificate Revo- 

cation List) . 

Erfiillt das Zertifikat eines der oben genannten Kriterien 
nicht/ so markiert der Verkaufer es als ungiiltig und been- 

15 dete die Sitzung mit dem Kunden. 

Anderenf alls, also wenn das Zertifikat gultig ist, sendet 
der Verkaufer das Zertifikat des Kunden an die Bank oder 
an den Kreditkartenausgeber (Verify Account) , um die im 
Zertifikat angegebene Kreditkartennummer zu verif izieren . 

20 Diese Kreditkartennummer ist, wie bereits beschrieben, in 

der privaten Erweiterung des X.509 Zertifikats gespei- 
chert, und dort nur verschlusselt zu entnehmen. 

5. Die Bank uberpruft das vom Kunden empfangene X.509 Zerti- 
25 fikat. Die Uberprufung beinhaltet: 

Kommt das Zertifikat von einer vertrauenswiirdigen Zertifi- 
kat sautori tat, 

ist das Zertifikat abgelaufen, 

ist das Zertifikat in der CRL (Certificate Revocation 
30 List) und 

hat das Zertifikat die Erweiterungen, die die Informatio- 
nen iiber Kreditkartennummern oder Kontonummern enthalten. 

Ist das Zertifikat als gultig erkannt, so uberpruft die Bank 
35 nun den in der Erweiterung spezif izierten Account, Ist das 

Konto gesperrt oder uberzogen, dann sendet die Bank eine ne- 
gative Antwort an den Verkaufer. Es ist vorstellbar, dass ein 
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vordef inierter Set an Antwortcodes zu jedem moglichen Status 
des Kundenkontos definiert wird, um diesen Kundenstatus zu 
propagieren. 

1st jedoch das X.509 Zertifikat auch in diesem zweiten Check 
5 positiv uberpruft, das heisst, das Konto existiert und ist 

belastbar, so sendet die Bank einen speziellen Code, auch als 
Transaktionsnummer (TAN) bekannt, an den Verkaufer zuruck 
(Transaction Number) . Diese TAN ist in der Regel eine zufal- 
lige Zahl, die eindeutig diese Transaktion identif izieren 
10 soli. 

Diese Transaktionsnummer kann auch noch mit zwei Flags be- 
wahrt werden, einen "Angef ordert" und einen "Benutzt" Flag. 
Wenn die Transaktionsnummer zu dem Verkaufer ge sendet wird, 
dann wird der Zustand auf "Angef ordert" gesetzt. So kann die 
15 Bank Falschungsversuche durch Kopieren dieser Transaktions- 
nummer verhindern. Die Bank verschlusselt die Transaktions- 
nummer mit dem offentlichen Schlussel des Verkaufers und sen- 
det es an den Verkaufer zuruck. 

20 6. Der Verkaufer evaluiert die Antwort der Bank und ent- 



25 



30 



35 



schlusselt diese mit seinem privaten Schlussel. 

Ist die Antwort negativ, so beendet der Verkaufer die Sit- 

zung mit dem Kunden. 

Im anderen Fall, wenn die Antwort positiv ist, so muss ei- 
ne Transaktionsnummer von der Bank enthalten sein. Der 
Verkaufer formatiert die Antwort auf die Kaufanfrage des 
Kunden, diese Antwort ist beispielhaft in der Figur 3b 
dargestellt. Enthalten ist hier der Betrag (Amount), der 
Name des Kunden (Client Name) , die verschlusselte Konto- 
nummer, welche aus dem X.509 Zertifikat entnommen wurde 
(Konto Encrypted) , dann die angef orderten Waren (Waren) 
und die von Bank gelieferte Transaktionsnummer (TN) . Die 
Uhrzeit (Zeit) entspricht der Zeit am Server des Verkau- 
fers und der Name (Name) entspricht dem offiziellen Namen 
des Verkaufers, so wie es auch in ublichen Kreditkarten- 
transaktionen verwendet wird. Der Kundenname und das Kun- 
denkonto wird vom Zertifikat des Kunden entnommen. Um eine 
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erhohte Privacy zu garantieren, konnen auch die eingefug- 
ten Waren verschlusselt sein, hier dargestellt durch eine 
Hash-Funktion. Der komplette Datensatz wird dann rnit dem 
offentlichen Schlussel des Kunden verschlusselt und zum 
5 Kunden geschickt (Request Sign Order) . Vorteilhaf terweise 

speichert der Verkaufer diese Anforderung, insbesondere 
die Adresse und die Waren (Waren) , fur einen spateren 
Versendungsprozess . 

7. Der Kunde empfangt die Nachricht vom Verkaufer und sig- 
niert diese digital (Dig. Signatur) . Dieses ist zu erken- 
nen in der Figur 3c. Fur die Signierung verwendet er sei- 
nen privaten Schlussel (Private Key Kunde) . Wahlweise kann 
er mit Hilfe der Hash-Funktion seine Waren uberprufen. 
Die digitale Signatur spielt hierbei eine doppelte Rolle: 
Zum Einen stellt es sicher, dass die Daten wahren der U- 
bertragung nicht geandert worden sind und zum Anderen sei- 
tens der angeschriebene Kunde dem Kunden entspricht, der 
die ursprungliche Anforderung gesendet hat. Damit stellt 
es sicher, dass es sich tatsachlich urn den Inhaber des 
X.509 Zertifikates handelt. Der Kunde verschlusselt nun 
die komplette Nachricht mit dem offentlichen Schlussel des 
Verkaufers und sendet es an den Verkaufer zuruck (Sign Or- 
der) . 

8. Der Verkaufer empfangt die verschliisselte Nachricht und 
entschliisselt sie mit seinem privaten Schlussel. Dann ver- 
schlusselt er sie mit dem offentlichen Schlussel der Bank 
oder des Kreditkarteninstitutes . In diesem Schritt handelt 
der Verkaufer nur in einer Router funkt ion (Verify Sign Or- 
der) . Das Format der Nachricht entspricht demselben wie in 
Schritt 7, siehe Figur 3c. 

9. Die Bank entschliisselt die vom Verkaufer empfangene Nach- 
35 richt mit seinem privaten Schlussel. Danach wird die Sig- 
natur der Kundenanf rage verifiziert. Die Transaktionsnum- 
mer, die in der Nachricht vorhanden sein muss, muss auf 



10 



15 



20 



25 



30 
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"Angef ordert" gesetzt sein, wie vorher geschrieben. Ande- 
renfalls ist dies ein Hinweis, dass der Verkaufer versucht 
hat, die Nachricht zu duplizieren. Nach Empfang der Trans- 
aktionsnummer setzt die Bank das zweite Flag fur die 
5 Transaktionsnummer in seiner Datenbank auf "Benutzt" - 

Die Bank generiert nun einen Autorisierungscode und forma- 
tiert die Daten wie in der Figur 3d angezeigt. Uhrzeit 
(Zeit) und Bankname entsprechen dem in Schritt 6 beschrie- 
benem. Sicherheitshalber kann die Bank nun diese Nachricht 
10 digital unterschreiben mit ihrem Autorisierungscode. Die 

komplette Nachricht wird danach verschliisselt mit Hilfe 
des of fentlichen Schlussels des Verkaufers und an den Ver- 
kaufer gesendet (Auth. Code) . 

15 10. Sofern der Autorisierungscode der empfangenen Nachricht 
positiv ist, versendet der Verkaufer seine Waren oder 
macht den angef orderten Dienst fiir den Kaufer verfugbar. 
Weiterhin zieht er den angeforderten Geldbetrag nun vom 
Kreditkarteninstitut oder der Bank ein. Dann informiert 

20 der Verkaufer den Kunden, dass die Transaktion erfolgreich 

durchgefuhrt wurde (Notification) . Diese Nachricht wird 
wieder mit dem offentlichen Schlussel des Kunden ver- 
schliisselt . 

25 Der im Vergangenem beschriebene Transaktionsprozess kann aber 
auch in der Anzahl der Schritte reduziert werden (siehe hier- 
fur die Figur 5) . Voraussetzung ist in diesem Fall, dass zwi- 
schen jeweils zwei Teilnehmern, dem Kunden und dem Verkaufer, 
und dem Verkaufer und der Bank, eine sichere Kommunikation, 

30 beispielsweise uber SSL etabliert ist. Weiterhin wird ange- 

nornmen, dass eine gegenseitige Authentisierung, basierend auf 
den X.509 Zertif ikaten, zwischen den jeweiligen Teilnehmern 
bereits geschehen ist. 

35 Die Schritte 1 bis 8 werden sequentiell ausgefuhrt. Das For- 
mat der Datenpakete ist dasselbe wie in dem vorangegangenen 
Beispiel der Figur 6 beschrieben. In diesem Fall besteht kei- 
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ne Erfordernis fur eine Verschlusselung, da die Verschlusse- 
lung durch die SSL-Verbindung bereits gewahrleistet ist. Des- 
halb spart man in diesem Prozess zwei Schritte ein. Im Prin- 
zip sind die ersten zwei Schritte des Prozesses in Figur 6 
5 eingespart, so dass der Schritt 1 der Figur 5 dem Schritt 3 
der Figur 6 entspricht. Der Schritt 2 der Figur 5 entspricht 
dem Schritt 4 der Figur 6 und so fort. 

Ein Verkauf svorgang mit einem minimalen Nachrichtenaustausch 
10 ist in der Figur 4 dargestellt. In den beiden vorangehenden 

Beispielen wurde der Vorgang in zwei Schritten durchgefuhrt, 

das Bestellen und im zweiten Schritt die Signierung der Be- 

stellung. Figur 4 zeigt nun einen Vorgang, wo beide Schritte 

in einem Schritt zusammengef asst werden. 
15 Weiterhin ist in diesem Vorgehen auch keine Transaktionsnum- 

mer der Bank erf orderlich . Die Transaktionsnummer wird in 

diesem Fall von dem Kunden selber erzeugt. 

Der Nachrichtenf luss funktioniert im Folgenden: 
20 1- Der Nutzer bereitet eine Anforderung (Sign Kaufanforde- 

rung) vor, er generiert sich eine Transaktionsnummer (die 



25 



35 



30 



in diesem Fall eine wirkliche Zuf allsnummer ist TN) , und 
die gegen Kopierattacken verwendet wird. Das Format der 
Nachricht ist in der Figur 3e abgebildet. Das Feld "Zeit" 
reprasentiert die Transaktionszeit beim Kunden. Name und 
Kundennummer sind Werte, die aus dem Zertifikat des Kunden 
X.509 entnommen wurden. Die Summe (Betrag) reprasentiert 
die Hohe der Summe dieser Kauf transaktion . 
Der Verkaufer (Merchant) ist als Name oder auch als ID, 
wie liblicherweise in Kreditkartentransaktionen, verwendet. 
Ein Hashwert ermoglicht es, dem Kunden seine Auflistung 
der georderten Waren gegenliber der Bank zu verschltisseln, 
der Hash-Algorithmus ist dem Fachmann bekannt. 
Weiterhin ist in der Nachricht eine digitale Signatur 
(dig. Signatur) enthalten, die die vorangegangenen Daten 
signiert. Diese Signatur versichert dem Verkaufer und der 
Bank, dass der Kunde die Transaktion selber initiiert hat, 
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und dass er der Besitzer des korrespondierenden privaten 
Schlussels ist und die Transaktionsdaten wahrend der Uber 
tragung nicht geandert worden sind. 

Das Feld "Waren" (Goods) reprasentiert die vom Kaufer aus 
5 gewahlten Waren, die gekauft werden sollen oder auch die 

Dienstleistung, dieses Feld muss fur den Verkaufer lesbar 
sein, urn im Zweifelsfall die Anforderung vervollstandigen 
zu konnen . 

Der Kunde hangt sein X.509 Zertifikat mit dem in den Ex- 
10 tensions enthaltenen verschliisselten Kreditkartennummern 

an die Nachricht an. Wenn diese Nachricht uber das Inter- 
net verteilt wird, dann sollte der Kunde diese Nachricht 
zusatzlich mit dem offentlichen Schliissel des Verkaufers 
verschlusseln . 

15 

2. Der Verkaufer uberpruft das Zertifikat des Kunden auf fol 
gende Bedingungen: 

Ist das Zertifikat von einer vertrauenswurdigen Autori 
tat ausgegeben, 

20 - ist die Lebensdauer des Zertifikats abgelaufen, und 

ist das Zertifikat in der CRL (Certificate Revocation 
List) . 

Wenn die Uberprufung des Zertifikats eine Fehlermeldung 
25 produziert, dann markiert der Verkaufer dieses als ungul- 

tig und beendet die Sitzung mit dem Kunden. Der Verkaufer 
hat aufierdera die Moglichkeit, die digitale Signatur zu 
prufen, beispielsweise indem er uberpruft, ob der Kunde 
den entsprechenden privaten Schliissel besitzt. Der Verkau 
30 fer entnimmt das Feld "Waren" (Goods) aus der enthaltenen 

Nachricht urn sicherzustellen, dass diese Inf ormationen 
nicht an die Bank gelangen, und leitet die restliche Nach 
richt an die Bank weiter (Verify Sign Order) . 



35 3. Die Bank uberpruft das X.509 Zertifikat des Kunden auf 
Grund folgender Punkte : 
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1st das Zertifikat von einer vertrauenswurdigen Autoritat 
ausgestellt, 

ist das Zertifikat abgelaufen, 
ist das Zertifikat in der CRL enthalten und 
5 - hat das Zertifikat die privaten Erweiterungen, die die 

Kreditkartennummer oder Kontonummer des Kunden enthalten. 



Stellt sich das Zertifikat als gultig heraus, so verifi- 
ziert die Bank die digitale Signatur urn sicherzustellen, 

10 dass die Transaktion tatsachlich vom Kunden ausgelost wur- 

de. Danach uberpriift die Bank das Konto des Kunden oder 
das Kreditkartenkonto, welches in dem X.509 Zertifikat 
enthalten war. Ist diese Kontonummer gesperrt oder ist das 
Konto uberzogen, so sendet die Bank eine negative Antwort 

15 an den Verkaufer. Im anderen Fall, also wenn das Konto 

verfiigbar ist f so sendet die Bank eine Antwort (Auth. Co- 
de) zuruck, wie sie in der Figur 3f dargestellt ist. In 
dies em Fall bezeichnet das Feld "Name" den Namen der Bank 
oder des Kreditkarteninstituts - Die Bank signiert diese 

20 Nachricht danach mit ihrem privaten Schllissel (signiert 

mit Private Key der Bank) . 

4. Im letzten Schritt macht der Verkaufer nach Erhalt des po- 
sitiven Autorisierungscodes die Waren fur die Kaufer zu- 
25 ganglich oder auch die angef orderten Dienstleistungen (No- 

tification) . Weiterhin zieht er das angeforderte Geld vom 
Kreditkarteninstitut ein . 



Das Protokoll, das in diesem Abschnitt beschrieben ist, kann 
30 beispielsweise auch iiber http (HyperText Transfer Protocol) 

oder https (HyperText Transfer Protocol Secure) ablaufen. Im 

Falle von http sollten die Nachrichten mit dem jeweiligen of- 

fentlichen Schlussel des Absenders verschlusselt werden. 

Falls zwischen dem Verkaufer und der Bank ein anderes siche- 
35 res Netzwerk existiert, beispielweise ein privates Banknetz 

oder ein VPN (Virtual Private Network) , so kann auf eine Ver- 

schliisselung verzichtet werden. 
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Die Figuren 3g und 3h stellen weitere Nachrichtenf ormate dar, 
die alternativ zu den bereits beschriebenen, aus den Figuren 
3a bis 3f verwendet werden konnen. Die Nachricht aus der Fi- 
5 gur 3g ist beispielsweise ein anderes Format fur die Nach- 
richt aus der Figur 3c. Die Figur 3h stellt ein Nachrichten- 
format entsprechend der Figur 3d dar. Dies soil deutlich ma- 
chen, dass die entsprechenden Nachrichtenf ormate nur bei- 
spielhafter Natur sind und selbstverstandlich beispielsweise 
10 durch erganzende Felder verandert werden konnen. 

Der Prozess, der in Figur 7 dargestellt ist, entspricht im 
Wesentlichen dem Vorgehen der Figur 6 mit der einzigen Aus- 
nahme, dass die negativen Antworten (Return (False) ) bei 
15 fehlgeschlagener Uberprufung von Zertifikaten mit eingefugt 
sind. 

Eine Realisierung der erf indungsgemafien Idee wurde bereits 
erprobt. Hier wurde das Windows XP als Betriebssystems ver- 

20 wendet, . NET Studio als Entwicklungsumgebung WES (Web Service 
Enhancements) als ein Extramodul fur die Erzeugung von X.509 
Zertifikaten. CAPICOM-Module fur die Manipulation der Zerti- 
fikate, zum Beispiel, Signieren, Entschlusseln, Verschlus- 
seln, Verifizieren usw. Open SSL fur die Herausgabe der not- 

25 wendigen Zertif ikatextensions . Als Smart Card die Infineon 

Secrypt Smart Card und zugehdrigen Tools fur die Installation 
der Zertif ikate. 
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Patentanspruche 

1. Verfahren zur Ubermittlung von ersten Inf ormationen (Wa- 
ren) von einem Nutzer (Kunde) eines Telekommunikationsnet- 

5 zes an einen ersten Anbieter (Verkaufer) 

und von zweiten Inf ormationen (X.509 Identity Certificate) 
von diesem Nutzer (Kunde) an einen zweiten Anbieter 
(Bank) , 

bei dem die ersten Inf ormationen (Waren) gemafi Vorgaben 
10 des ersten Anbieters (Verkaufer) verschlusselt sein konnen 

und 

bei dem die zweiten Inf ormationen einen ein- oder mehrtei- 
ligen Bestandteil (Zahlungs Info) enthalten, der gemafi 
Vorgaben des zweiten Anbieters (Bank) verschlusselt ist 
15 und bei dem die Inf ormationen in einer gemeinsamen Infor- 

mationseinheit versendet werden. 

2. Verfahren zur Ubermittlung von ersten Inf ormationen (Wa- 

ren) von einem Nutzer (Kunde) eines Telekommunikations- 
20 netzes an einen ersten Anbieter (Verkaufer) 

und von zweiten Inf ormationen (X.509 Attribute Certifica- 
te) von diesem Nutzer (Kunde) an einen zweiten Anbieter 
(Bank) , 

bei dem die ersten Inf ormationen gemafi Vorgaben des ersten 
25 Anbieters (Verkaufer) verschlusselt sein konnen und 

bei dem die zweiten Inf ormationen einen ein- oder mehrtei- 
ligen Bestandteil (Zahlungs Info) enthalten, der gemafi 
Vorgaben des zweiten Anbieters (Bank) verschlusselt ist 
und bei dem die zweiten Inf ormationen von dem ersten oder 
30 zweiten Anbieter aus einem von dem ersten und zweiten An- 

bieter zugreifbaren Datenspeicher abgelegt sind. 

3. Verfahren nach Patentanspruch 1 oder 2, 
dadurch gekennzeichnet , dass 

35 zur Ablage der zweiten Inf ormationen eine private Erweite- 

rung eines Zertifikates gemafi dem Standard X.509 verwendet 
wird. 
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4. Verfahren nach einem der vorigen Patentanspruche, 
dadurch gekennzeichnet, dass 

es fur eine Zahlungstransaktion verwendet wird und die u- 
5 bertragenen ersten und/oder zweiten Inf ormationen sich auf 

die Zahlungstransaktion beziehen. 

5. Verfahren nach Patentanspruch 4, 
dadurch gekennzeichnet , dass 

10 dem Zahlungsvorgang von dem zweiten Anbieter oder von dern 

Nutzer eine eindeutige Transaktionsnuiraner (TAN) zugewiesen 
wird. 

6. Verfahren nach Patentanspruch 4, 
15 dadurch gekennzeichnet, dass 

eine Identity Certificate Extension verwendet wird. 

7. Verfahren nach Patentanspruch 4, 
dadurch gekennzeichnet, dass 

20 eine Attribute Certificate Extension verwendet wird. 

8. Verfahren nach Patentanspruch 7 , 
dadurch gekennzeichnet, dass 

ein Attribute Certificate genau einmal verwendet werden 
25 kann. 

9. Verfahren nach einem der vorigen Patentanspruche, 
dadurch gekennzeichnet, dass 

zur Ablage des Zertifikats ein geeignetes Speichermedium, 
30 insbesondere eine Smart Card, ein Smart Dongle oder ein 

kontaktlos abzulesendes Speichermedium verwendet wird. 

10. Verfahren nach einem der vorigen Patentanspruche, 
dadurch gekennzeichnet, dass 

35 das Zertifikat mit einem Passwort geschiitzt auf dem Spei- 

chermedium abgelegt ist. 
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FIG 2A 



Attribut 


Encrypted Attribut Erweiterung 


VISA 

American Express(AMEX) 
MasterCard 
Bank Konto 
Adresse 

Versicherungsnummer 


E ( K VISAPublicKey, CreditCardNumber) 
E ( K AMEXPublicKey, CreditCardNumber) 
E ( K MasterCardPublicKey, CreditCardNumber) 
E ( K BankPublicKey, AccountNumber) 
E( K PostPubiicKey, Address) 
E ( K lnsurancePublicKey, InsuranceNumber) 



Tabelle 1.1: New certificate extensions. 



FIG 2B 



OID 



Wert 



1.3. 6.1.4.15601 



3. 6.1 
3. 6.1 



4.15601 
4.15601 



1.3. 6.1.4.15601 
1.3. 6.1.4.15601 
1.3. 6.1.4.15601 
1.3. 6.1.4.15601.6 



Root node of new extensions 

Encrypted value: VISA credit card number 

Encrypted value: American Express credit card number 

Encrypted value: MasterCard credit card number 

Encrypted value: Bank Konto Nummer 

Encrypted value: Adresse 

Encrypted value: Versicherungsnummer 



Tabelle 1.2: New private OlDs. 
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